1. Technical Field
The present invention generally relates to distributed data processing systems and in particular to server programming in distributed data processing systems. Still more particularly, the present invention relates to improved techniques for treating messaging tasks as programming objects in distributed data processing systems.
2. Description of the Related Art
Java(trademark) (a trademark of Sun Microsystems, Inc. of San Jose, Calif.) is a software development language that enables programmers to create program applications and small programs called applets. A virtual machine is generated by Java(trademark) that provides a control interface allowing a Java(trademark) program to overlay and operate on virtually any operating system.
Java(trademark) (Java) was developed with distributed computing, low to no administration and platform independence in mind. The Java(trademark) platform for enterprise-capable Java(trademark) computing utilizes Enterprise JavaBeans(trademark) (trademark of Sun Microsystems) (EJBean) technology that provides for the development and deployment of reusable server components. EJBean server components are individual specialized applications that run in an application server. Traditionally, in a client/server application, the client contains control logic for manipulating a database management system on the server.
EJBeans are designed to support high scalability using a multitier distributed application architecture (architecture that has multiple application components) and the multitier orientation provides many advantages over traditional client/server architectures. EJBean components contain no system level programming, include only business related logic and are fully portable across any EJBean compliant server and any Operating System (OS). Some advantages to EJBean components include reusability, performance, scalability, wire protocol neutral architecture and manageability among others.
Locating logic, for manipulating data, on one or more servers allows an application to operate in multi-processing and multi-threaded systems. Server components can be replicated and distributed across multiple systems enabling multi-tier systems with a scalability of essentially no limit. With a multi-tier environment, reliability is high and manageability is easier because most of the application logic is on the server.
A server component is a reusable software application that performs specific functions and is accessible to any other application through the server component""s interface. A server component can be developed for one application and reused in another application that may use the function. Basically, server components are basic building blocks that have specific, published functions that may be combined with other components and applications into a configuration that performs a task designed by a developer.
Traditionally, a Java Virtual Machine (JVM) allows a Java application to run on any operating system, but server side components require proprietary programming interfaces based on vendor software and hardware. EJBean server components are portable and virtually vendor-independent on all Java EJBean compliant application servers. With server component portability, increased scalability, reliability and re-usability, EJBean components can be moved from one execution environment to another without requiring any recoding. Determining whether a new component is valid is a problem that accompanies portability and reusability of EJBean components. EJBean components are required to implement a specific set of interfaces with the container that encloses the beans so the container can manage and control the bean. If the component has a purported function and is moved from one execution environment to another, the component should be validated before being deployed throughout the system served by the EJBean compliant server.
Deploying an EJB involves introspecting classes, reading serialized deployment data, generating code, compiling the generated code and packaging it all up for installation. This can take a significant amount of time to complete, particularly if the platform uses C++ as part of the generated code. The largest portion of time is spent compiling the generated code and can take hours to complete depending on the speed of the host, the amount of code being generated, and the language being used.
Component Broker, an International Business Machines Corporation (IBM) product, is a business tool, which integrates the open standards contained in the Object Management Group""s Common Object Request Broker Architecture (CORBA) initiative. Component Broker (CB) provides server-based support for customers to build, execute, and manage applications across network computing environments. Component Broker technology includes: a programming model that enables data access to be partitioned from business logic; a CORBA 2.0 compliant ORB, using the widely accepted Internet Interoperability Protocol (IIOP) standard to communicate with other complying ORB""s; an application runtime environment, providing integration and management of object services; management of distributed applications interactions with networked computing hardware/software resources (for monitoring, resource allocation, unit of work); support for Web (Java) clients, traditional CORBA clients, ActiveX clients, and an ever-increasing number of nontraditional clients, including kiosks, ATM""s, and so on; and multi-tier visual development tools for the major Object Oriented Programming languages.
IBM""s Component Broker Connector provides support for the EJB specification; Component Broker is an EJB server environment. It provides the qualities of service prescribed by the EJB specification and allows developers to build enterprise application business objects using the EJB programming model. Further details of the MQSeries Application Adaptor and its integration with Component Broker may be found in xe2x80x9cMQSeries Application Adaptor Concepts and Development Guide Version 3.0, xe2x80x9d available from the International Business Machines Corporation and hereby incorporated by reference.
It would be desirable to provide EJB support for message queue (MQ) integration, to provide Component Broker customers with an EJB programming interface on the client side that allows them to treat the MQ objects as EJBs just as they do other business objects in the CB environment. In present systems, this has proven difficult for several reasons.
First, the base interfaces for both inbound and outbound message homes of Component Broker inherit from CosLifeCycle::GenericFactory rather than from IHome, the typical base interface for CB homes. This is purposefully done to remove the xe2x80x9ccreateFromxe2x80x9d and xe2x80x9cfindByxe2x80x9d methods from the programming interface. Every Component Broker managed object class has an instance of a Factory associated with it, which provides a set of interfaces for creating instances of a managed object. The Factory gets some of its interface from the base class CosLifeCycle::GenericFactory.
The createFromPrimaryKeyString method is introduced in the IManagedClient::IHome interface supplied by Component Broker. This interface specializes the CosLifeCycle::GenericFactory interface and plays the role of factory for Component Broker managed objects. Object providers can implement and provide a tailored subclass of this interface, or can use the implementation of IHome provided. Homes are at well-known locations in the Naming Service. The input required for the factory finder is the name of the interface of the class that you want this factory to make instances of. This, and other details of Component Broker programming may be found in the Component Broker xe2x80x9cProgramming GuideVersion 3.0, xe2x80x9d available from the International Business Machines Corporation and hereby incorporated by reference.
Next, the xe2x80x9cputxe2x80x9d method on OMQueue does not return an OM reference, as a xe2x80x9ccreatexe2x80x9d method would normally do. This is reasonable, since there is nothing that the client can do with an OM once it is put to the queue. However, this is a further deviation from the xe2x80x9ccreate from homexe2x80x9d approach currently required by Component Broker.
Third, the message key interfaces are developed primarily to be conformant to CB programming model. In fact, OutboundMessageKey is never used at all and InboundMessageKey""s use is completely hidden from the client.
Further, the xe2x80x9cgetxe2x80x9d method""s returning an incoming message (IM) instance seems to be a reflection of missing object-by-value support, since there is not much to be done with the returned IM instances, except to retrieve message fields from them. This can be done just as well with MessageTemplates if Object By Value (OBV) were available.
Therefore, it would be desirable to provide a system and method for EJB support for message queue (MQ) integration, so that programmers of systems such as Component Broker can treat the MQ objects as Enterprise JavaBeans, as with other business objects.
It is therefore one object of the present invention to provide an improved distributed data processing system.
It is another object of the present invention to provide improved server programming in distributed data processing systems.
It is yet another object of the present invention to provide improved techniques for treating messaging tasks as programming objects in distributed data processing systems.
The foregoing objects are achieved as is now described.
According to the preferred embodiment, a stateful EJB session bean is used as the front end to client calls. In this configuration, a queue is represented by a session bean instance. xe2x80x9cPutxe2x80x9d and xe2x80x9cgetxe2x80x9d are called on the relevant session bean instances. Thus, for example, a client, instead of first finding a home for a given type of OMs then calling xe2x80x9cputxe2x80x9d on the home to send out messages, will find a session bean home, create a session bean instance corresponding to a queue, and call xe2x80x9cputxe2x80x9d on the bean instance to send messages. In this manner, the message queue can be managed using standard EJB techniques.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.